home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1994 March / Internet Info CD-ROM (Walnut Creek) (March 1994).iso / inet / ietf / alertman / alertman-minutes-89july.txt < prev    next >
Text File  |  1993-02-17  |  7KB  |  188 lines
  1.                                         1
  2. Alert Management Working Group
  3. Chairperson:  Louis Steinberg/IBM
  4.  
  5.  
  6.  
  7.  
  8.  
  9. CURRENT MEETING REPORT
  10. Reported by Lee Oattes
  11.  
  12.  
  13.  
  14. AGENDA
  15.  
  16.  
  17.    o Introduction
  18.  
  19.    o Discussion of draft flow control document
  20.  
  21.    o Preliminary discussion of alert-generation document note:  this was
  22.      shelved due to a lack of time
  23.  
  24.  
  25. ATTENDEES
  26.  
  27.  
  28.        1. Bierbaum, Neal/vitam6!bierbaum@vitam6
  29.  
  30.        2. Carter, Glen/gcarter@ddn1.dca.mil
  31.  
  32.        3. Cohn, George/geo@ub.com
  33.  
  34.        4. Cook, John/cook@chipcom.com
  35.  
  36.        5. Denny, Barbara/denny@sri.com
  37.  
  38.        6. Easterday, Tom/tom@nisca.ircc.ohio-state.edu
  39.  
  40.        7. Edwards, David/dle@cisco.com
  41.  
  42.        8. Fedor, Mark/fedor@nisc.nyser.net
  43.  
  44.        9. Hunter, Steven/hunter@ccc.mfecc.llnl.gov
  45.  
  46.       10. Kincl, Norman/kincl@iag.hp.com
  47.  
  48.       11. Malkin, Gary/gmalkin@proteon.com
  49.  
  50.       12. Oattes, Lee/oattes@utcs.utoronto.ca
  51.  
  52.       13. Paw, Edison/esp@esd.ecom.com
  53.  
  54.       14. Replogle, Joel/replogle@ncsa.uiuc.edu
  55.  
  56.       15. Salo, Tim/tjs@msc.umn.edu
  57.  
  58.       16. Sheridan, Jim/jsherida@ibm.com
  59.  
  60.       17. Taft, Vladimir/vtaft@hpinddf.hp.com
  61.  
  62.  
  63.  
  64.                                         2
  65. 18. Waldbusser, Steve/sw0l@andrew.cmu.edu
  66.  
  67. 19. Wintringham, Dan/danw@osc.edu
  68. 20. Steinberg, Louis/louiss@ibm.com
  69.  
  70.  
  71.  
  72.                                   3
  73. MINUTES
  74.  
  75.  
  76.   1. The meeting of the Alert Management Working Group began with an
  77.      introduction from the Chairman (Lou Steinberg).
  78.  
  79.   2. A discussion of several independent implementations of feedback/pin and
  80.      polled, logged alerts led to an agreement to adopt these mechanisms in
  81.      some form.
  82.  
  83.   3. The following questions were answered by discussion and consensus:
  84.  
  85.       (a) Can we have a read-only alerts_enabled mib object, by limiting the
  86.           transmission rate of alerts (no shutoff) and not use feedback?  No.
  87.           We need a total shutoff mechanism in case a number of alert
  88.           generators are "screaming" all at once.  The total traffic might be
  89.           too much for the manager, and this "stable" situation cannot
  90.           improve (while a disabling mechanism would tend to be
  91.           self-correcting).
  92.           Total shutoff implies the use of a resetable, read-write mib
  93.           object.
  94.           An automated, timer-based reset mechanism was discussed but it was
  95.           felt that such a system might tend to sync resets of multiple
  96.           generators and could still lead to an over-reporting condition.
  97.  
  98.       (b) Might an automated-reset of alerts_enabled from the manager station
  99.           create a "blast-off-blast-off..." alert traffic pattern?
  100.           Yes, but such a manager would still tend to only get as much
  101.           traffic as he could handle.  A re-enable would only be sent when
  102.           the manager isn't swamped (i.e., is capable of sending one).
  103.           A manager experiencing such a traffic pattern should readjust his
  104.           window prior to setting alerts_enabled TRUE.
  105.  
  106.       (c) When pin disables alerts due to the generation of many similar
  107.           alerts (e.g., link flapping) might we also lose an unrelated alert
  108.           from the same system prior to resetting alerts_enabled?
  109.           Yes, but the rate limiting (as opposed to shutoff) technique has
  110.           the same problem; the probability of sending a single, specific
  111.           alert is much lower than the probability of sending any one of many
  112.           identical alerts.
  113.           This problem is minimized by using polled, logged alerts along with
  114.           feedback/pin (could still lose alerts if log is overwritten).
  115.  
  116.       (d) Should we allow the implementation to decide if alerts are totally
  117.           disabled or limited to a max rate?  No.
  118.           Implementations should be consistent since this affects the way we
  119.           manage our alert generators.
  120.  
  121.  
  122.  
  123.                                         4
  124.     (e) Can the alert log in polled, logged alerts be overfilled?
  125.         Yes, but the standard suggests that a manager should attempt to
  126.  
  127.         keep the log empty by removing known alerts.
  128.         If an individual implementation has no mechanism for removing old
  129.         alerts (no set) then the log must wrap when full and the manager
  130.         might lose alerts.
  131.  
  132.     (f) If using the SNMP get-next, do we want the oldest logged element
  133.         first, or the newest first?
  134.         Clearly the manager wants the oldest first if a full log will
  135.         wrap...this gives him the most chance to see the oldest alert (in a
  136.         full log) before losing it.
  137.         No real concensus here.  It seems as though this should be
  138.         implementation specific since it only applies to SNMP, and since
  139.         the log, actually being a table, makes this a question of "are new
  140.         table entries added at the table top or bottom?".
  141.  
  142.     (g) Can we shrink the log size by stripping out only the "important"
  143.         information from each alert?
  144.         We can, but this is something we decided we shouldn't do.  It
  145.         requires a different parser at the manager (can't run it through
  146.         the alert parser), and we did not know how do decide what
  147.         information might be needed (it varied with the protocol and alert
  148.         type).
  149.  
  150.     (h) How about only logging alerts, and sending an "alert logged" alert
  151.         for each new log entry?  The manager gets the asynch.  "alert
  152.         logged" notice and reads the alert log to determine what happened.
  153.         While this is an interesting concept, it was felt that it might
  154.         tend to aggravate some of the other logging problems (e.g., if the
  155.         log is filled and not over-writing, the only chance of getting the
  156.         alert information is from the async alert...this removes the asynch
  157.         alert information and replaces it with "see the log" information).
  158.  
  159.     (i) A discussion of the cpu cycles and memory needed for keeping a log
  160.         followed.  Since the log size might be settable (to 0) it was felt
  161.         that systems could allow managers to disable logging.  It was also
  162.         felt that the performance and memory hits were not large, but
  163.         numbers to confirm this were not available.
  164.  
  165. 4. The following were decided by vote:
  166.  
  167.     (a) Feedback/Pin
  168.         Mandatory mib objects:
  169.  
  170.  
  171.  
  172.                                       5
  173.          alerts_enabled   read/ write
  174.          window (time)    read/ optional write
  175.  
  176.          max_alerts       read/ optional write
  177.     Do not include alert counters as mib objects for this document.
  178.     Individual implementors will decide if they need total dropped
  179.     and/or sent, but not everybody likes the idea of adding more
  180.     counters as (even optional) mib objects.
  181.     Do not optionally allow a reduced rate mode on the over reporting
  182.     condition...require total async.  Alerts to be shutoff for reasons
  183.     given in earlier discussion.
  184.  
  185. (b) Polled, Logged Alerts Remove time field from the table, as most
  186.     alerts are time stamped and the information in an alert should be
  187.     defined by the protocol...not us.
  188.